<!DOCTYPE html>
<html lang="en-us">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    
<meta charset="UTF-8">
<title>Profile API | Elasticsearch Guide [7.7] | Elastic</title>
<link rel="home" href="index.html" title="Elasticsearch Guide [7.7]">
<link rel="up" href="search.html" title="Search APIs">
<link rel="prev" href="search-explain.html" title="Explain API">
<link rel="next" href="search-field-caps.html" title="Field Capabilities API">
<meta name="DC.type" content="Learn/Docs/Elasticsearch/Reference/7.7">
<meta name="DC.subject" content="Elasticsearch">
<meta name="DC.identifier" content="7.7">
<meta name="robots" content="noindex,nofollow">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://cdn.optimizely.com/js/18132920325.js"></script>
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
    <link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
    <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
    <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
    <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
    <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
    <link rel="manifest" href="/manifest.json">
    <meta name="apple-mobile-web-app-title" content="Elastic">
    <meta name="application-name" content="Elastic">
    <meta name="msapplication-TileColor" content="#ffffff">
    <meta name="msapplication-TileImage" content="/mstile-144x144.png">
    <meta name="theme-color" content="#ffffff">
    <meta name="naver-site-verification" content="936882c1853b701b3cef3721758d80535413dbfd">
    <meta name="yandex-verification" content="d8a47e95d0972434">
    <meta name="localized" content="true">
    <meta name="st:robots" content="follow,index">
    <meta property="og:image" content="https://www.elastic.co/static/images/elastic-logo-200.png">
    <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="apple-touch-icon-precomposed" sizes="64x64" href="/favicon_64x64_16bit.png">
    <link rel="apple-touch-icon-precomposed" sizes="32x32" href="/favicon_32x32.png">
    <link rel="apple-touch-icon-precomposed" sizes="16x16" href="/favicon_16x16.png">
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
    <link rel="stylesheet" type="text/css" href="/guide/static/styles.css">
  </head>

  <!--© 2015-2021 Elasticsearch B.V. Copying, publishing and/or distributing without written permission is strictly prohibited.-->

  <body>
    <!-- Google Tag Manager -->
    <script>dataLayer = [];</script><noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-58RLH5" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= '//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-58RLH5');</script>
    <!-- End Google Tag Manager -->

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-12395217-16"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'UA-12395217-16');
    </script>

    <!--BEGIN QUALTRICS WEBSITE FEEDBACK SNIPPET-->
    <script type="text/javascript">
      (function(){var g=function(e,h,f,g){
      this.get=function(a){for(var a=a+"=",c=document.cookie.split(";"),b=0,e=c.length;b<e;b++){for(var d=c[b];" "==d.charAt(0);)d=d.substring(1,d.length);if(0==d.indexOf(a))return d.substring(a.length,d.length)}return null};
      this.set=function(a,c){var b="",b=new Date;b.setTime(b.getTime()+6048E5);b="; expires="+b.toGMTString();document.cookie=a+"="+c+b+"; path=/; "};
      this.check=function(){var a=this.get(f);if(a)a=a.split(":");else if(100!=e)"v"==h&&(e=Math.random()>=e/100?0:100),a=[h,e,0],this.set(f,a.join(":"));else return!0;var c=a[1];if(100==c)return!0;switch(a[0]){case "v":return!1;case "r":return c=a[2]%Math.floor(100/c),a[2]++,this.set(f,a.join(":")),!c}return!0};
      this.go=function(){if(this.check()){var a=document.createElement("script");a.type="text/javascript";a.src=g;document.body&&document.body.appendChild(a)}};
      this.start=function(){var a=this;window.addEventListener?window.addEventListener("load",function(){a.go()},!1):window.attachEvent&&window.attachEvent("onload",function(){a.go()})}};
      try{(new g(100,"r","QSI_S_ZN_emkP0oSe9Qrn7kF","https://znemkp0ose9qrn7kf-elastic.siteintercept.qualtrics.com/WRSiteInterceptEngine/?Q_ZID=ZN_emkP0oSe9Qrn7kF")).start()}catch(i){}})();
    </script><div id="ZN_emkP0oSe9Qrn7kF"><!--DO NOT REMOVE-CONTENTS PLACED HERE--></div>
    <!--END WEBSITE FEEDBACK SNIPPET-->

    <div id="elastic-nav" style="display:none;"></div>
    <script src="https://www.elastic.co/elastic-nav.js"></script>

    <!-- Subnav -->
    <div>
      <div>
        <div class="tertiary-nav d-none d-md-block">
          <div class="container">
            <div class="p-t-b-15 d-flex justify-content-between nav-container">
              <div class="breadcrum-wrapper"><span><a href="/guide/" style="font-size: 14px; font-weight: 600; color: #000;">Docs</a></span></div>
            </div>
          </div>
        </div>
      </div>
    </div>

    <div class="main-container">
      <section id="content">
        <div class="content-wrapper">

          <section id="guide" lang="en">
            <div class="container">
              <div class="row">
                <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                  <!-- start body -->
                  <div class="page_header">
<strong>IMPORTANT</strong>: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
<a href="../current/index.html">current release documentation</a>.
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="rest-apis.html">REST APIs</a></span>
»
<span class="breadcrumb-link"><a href="search.html">Search APIs</a></span>
»
<span class="breadcrumb-node">Profile API</span>
</div>
<div class="navheader">
<span class="prev">
<a href="search-explain.html">« Explain API</a>
</span>
<span class="next">
<a href="search-field-caps.html">Field Capabilities API »</a>
</span>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="search-profile"></a>Profile API<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h2>
</div></div></div>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>The Profile API is a debugging tool and adds significant overhead to search execution.</p>
</div>
</div>
<p>Provides detailed timing information about the execution of individual
components in a search request.</p>
<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="search-profile-api-desc"></a>Description<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h3>
</div></div></div>
<p>The Profile API gives the user insight into how search requests are executed at
a low level so that the user can understand why certain requests are slow, and
take steps to improve them. Note that the Profile API,
<a class="xref" href="search-profile.html#profile-limitations" title="Limitations">amongst other things</a>, doesn’t measure network latency,
time spent in the search fetch phase, time spent while the requests spends in
queues or while merging shard responses on the coordinating node.</p>
<p>The output from the Profile API is <span class="strong strong"><strong>very</strong></span> verbose, especially for complicated
requests executed across many shards. Pretty-printing the response is
recommended to help understand the output.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="search-profile-api-example"></a>Examples<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h3>
</div></div></div>
<p>Any <code class="literal">_search</code> request can be profiled by adding a top-level <code class="literal">profile</code> parameter:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET /twitter/_search
{
  "profile": true,<a id="CO636-1"></a><i class="conum" data-value="1"></i>
  "query" : {
    "match" : { "message" : "some number" }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/2047.console"></div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO636-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Setting the top-level <code class="literal">profile</code> parameter to <code class="literal">true</code> will enable profiling
for the search.</p>
</td>
</tr>
</table>
</div>
<p>The API returns the following result:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
   "took": 25,
   "timed_out": false,
   "_shards": {
      "total": 1,
      "successful": 1,
      "skipped" : 0,
      "failed": 0
   },
   "hits": {
      "total" : {
          "value": 4,
          "relation": "eq"
      },
      "max_score": 0.5093388,
      "hits": [...] <a id="CO637-1"></a><i class="conum" data-value="1"></i>
   },
   "profile": {
     "shards": [
        {
           "id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]",
           "searches": [
              {
                 "query": [
                    {
                       "type": "BooleanQuery",
                       "description": "message:some message:number",
                       "time_in_nanos": "1873811",
                       "breakdown": {
                          "score": 51306,
                          "score_count": 4,
                          "build_scorer": 2935582,
                          "build_scorer_count": 1,
                          "match": 0,
                          "match_count": 0,
                          "create_weight": 919297,
                          "create_weight_count": 1,
                          "next_doc": 53876,
                          "next_doc_count": 5,
                          "advance": 0,
                          "advance_count": 0,
                          "compute_max_score": 0,
                          "compute_max_score_count": 0,
                          "shallow_advance": 0,
                          "shallow_advance_count": 0,
                          "set_min_competitive_score": 0,
                          "set_min_competitive_score_count": 0
                       },
                       "children": [
                          {
                             "type": "TermQuery",
                             "description": "message:some",
                             "time_in_nanos": "391943",
                             "breakdown": {
                                "score": 28776,
                                "score_count": 4,
                                "build_scorer": 784451,
                                "build_scorer_count": 1,
                                "match": 0,
                                "match_count": 0,
                                "create_weight": 1669564,
                                "create_weight_count": 1,
                                "next_doc": 10111,
                                "next_doc_count": 5,
                                "advance": 0,
                                "advance_count": 0,
                                "compute_max_score": 0,
                                "compute_max_score_count": 0,
                                "shallow_advance": 0,
                                "shallow_advance_count": 0,
                                "set_min_competitive_score": 0,
                                "set_min_competitive_score_count": 0
                             }
                          },
                          {
                             "type": "TermQuery",
                             "description": "message:number",
                             "time_in_nanos": "210682",
                             "breakdown": {
                                "score": 4552,
                                "score_count": 4,
                                "build_scorer": 42602,
                                "build_scorer_count": 1,
                                "match": 0,
                                "match_count": 0,
                                "create_weight": 89323,
                                "create_weight_count": 1,
                                "next_doc": 2852,
                                "next_doc_count": 5,
                                "advance": 0,
                                "advance_count": 0,
                                "compute_max_score": 0,
                                "compute_max_score_count": 0,
                                "shallow_advance": 0,
                                "shallow_advance_count": 0,
                                "set_min_competitive_score": 0,
                                "set_min_competitive_score_count": 0
                             }
                          }
                       ]
                    }
                 ],
                 "rewrite_time": 51443,
                 "collector": [
                    {
                       "name": "SimpleTopScoreDocCollector",
                       "reason": "search_top_hits",
                       "time_in_nanos": "32273"
                    }
                 ]
              }
           ],
           "aggregations": []
        }
     ]
   }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO637-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Search results are returned, but were omitted here for brevity.</p>
</td>
</tr>
</table>
</div>
<p>Even for a simple query, the response is relatively complicated.  Let’s break it
down piece-by-piece before moving to more complex examples.</p>
<p>The overall structure of the profile response is as follows:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
   "profile": {
        "shards": [
           {
              "id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]",  <a id="CO638-1"></a><i class="conum" data-value="1"></i>
              "searches": [
                 {
                    "query": [...],             <a id="CO638-2"></a><i class="conum" data-value="2"></i>
                    "rewrite_time": 51443,      <a id="CO638-3"></a><i class="conum" data-value="3"></i>
                    "collector": [...]          <a id="CO638-4"></a><i class="conum" data-value="4"></i>
                 }
              ],
              "aggregations": [...]             <a id="CO638-5"></a><i class="conum" data-value="5"></i>
           }
        ]
     }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO638-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>A profile is returned for each shard that participated in the response, and
is identified by a unique ID.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO638-2"><i class="conum" data-value="2"></i></a></p>
</td>
<td align="left" valign="top">
<p>Each profile contains a section which holds details about the query
execution.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO638-3"><i class="conum" data-value="3"></i></a></p>
</td>
<td align="left" valign="top">
<p>Each profile has a single time representing the cumulative rewrite time.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO638-4"><i class="conum" data-value="4"></i></a></p>
</td>
<td align="left" valign="top">
<p>Each profile also contains a section about the Lucene Collectors which run
the search.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO638-5"><i class="conum" data-value="5"></i></a></p>
</td>
<td align="left" valign="top">
<p>Each profile contains a section which holds the details about the
aggregation execution.</p>
</td>
</tr>
</table>
</div>
<p>Because a search request may be executed against one or more shards in an index,
and a search may cover one or more indices, the top level element in the profile
response is an array of <code class="literal">shard</code> objects. Each shard object lists its <code class="literal">id</code> which
uniquely identifies the shard.  The ID’s format is
<code class="literal">[nodeID][indexName][shardID]</code>.</p>
<p>The profile itself may consist of one or more "searches", where a search is a
query executed against the underlying Lucene index.  Most search requests
submitted by the user will only execute a single <code class="literal">search</code> against the Lucene
index. But occasionally multiple searches will be executed, such as including a
global aggregation (which needs to execute a secondary "match_all" query for the
global context).</p>
<p>Inside each <code class="literal">search</code> object there will be two arrays of profiled information:
a <code class="literal">query</code> array and a <code class="literal">collector</code> array.  Alongside the <code class="literal">search</code> object is an
<code class="literal">aggregations</code> object that contains the profile information for the
aggregations. In the future, more sections may be added, such as <code class="literal">suggest</code>,
<code class="literal">highlight</code>, etc.</p>
<p>There will also be a <code class="literal">rewrite</code> metric showing the total time spent rewriting the
query (in nanoseconds).</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>As with other statistics apis, the Profile API supports human readable outputs. This can be turned on by adding
<code class="literal">?human=true</code> to the query string. In this case, the output contains the additional <code class="literal">time</code> field containing rounded,
human readable timing information (e.g. <code class="literal">"time": "391,9ms"</code>, <code class="literal">"time": "123.3micros"</code>).</p>
</div>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="profiling-queries"></a>Profiling Queries<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h3>
</div></div></div>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>The details provided by the Profile API directly expose Lucene class names and concepts, which means
that complete interpretation of the results require fairly advanced knowledge of Lucene.  This
page attempts to give a crash-course in how Lucene executes queries so that you can use the Profile API to successfully
diagnose and debug queries, but it is only an overview.  For complete understanding, please refer
to Lucene’s documentation and, in places, the code.</p>
<p>With that said, a complete understanding is often not required to fix a slow query.  It is usually
sufficient to see that a particular component of a query is slow, and not necessarily understand why
the <code class="literal">advance</code> phase of that query is the cause, for example.</p>
</div>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="query-section"></a><code class="literal">query</code> Section<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The <code class="literal">query</code> section contains detailed timing of the query tree executed by
Lucene on a particular shard. The overall structure of this query tree will
resemble your original Elasticsearch query, but may be slightly (or sometimes
very) different.  It will also use similar but not always identical naming.
Using our previous <code class="literal">match</code> query example, let’s analyze the <code class="literal">query</code> section:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">"query": [
    {
       "type": "BooleanQuery",
       "description": "message:some message:number",
       "time_in_nanos": "1873811",
       "breakdown": {...},               <a id="CO639-1"></a><i class="conum" data-value="1"></i>
       "children": [
          {
             "type": "TermQuery",
             "description": "message:some",
             "time_in_nanos": "391943",
             "breakdown": {...}
          },
          {
             "type": "TermQuery",
             "description": "message:number",
             "time_in_nanos": "210682",
             "breakdown": {...}
          }
       ]
    }
]</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO639-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>The breakdown timings are omitted for simplicity.</p>
</td>
</tr>
</table>
</div>
<p>Based on the profile structure, we can see that our <code class="literal">match</code> query was rewritten
by Lucene into a BooleanQuery with two clauses (both holding a TermQuery).  The
<code class="literal">type</code> field displays the Lucene class name, and often aligns with the
equivalent name in Elasticsearch.  The <code class="literal">description</code> field displays the Lucene
explanation text for the query, and is made available to help differentiating
between parts of your query (e.g. both <code class="literal">message:search</code> and <code class="literal">message:test</code> are
TermQuery’s and would appear identical otherwise.</p>
<p>The <code class="literal">time_in_nanos</code> field shows that this query took ~1.8ms for the entire
BooleanQuery to execute.  The recorded time is inclusive of all children.</p>
<p>The <code class="literal">breakdown</code> field will give detailed stats about how the time was spent,
we’ll look at that in a moment.  Finally, the <code class="literal">children</code> array lists any
sub-queries that may be present.  Because we searched for two values ("search
test"), our BooleanQuery holds two children TermQueries.  They have identical
information (type, time, breakdown, etc).  Children are allowed to have their
own children.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_timing_breakdown"></a>Timing Breakdown<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The <code class="literal">breakdown</code> component lists detailed timing statistics about low-level
Lucene execution:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">"breakdown": {
   "score": 51306,
   "score_count": 4,
   "build_scorer": 2935582,
   "build_scorer_count": 1,
   "match": 0,
   "match_count": 0,
   "create_weight": 919297,
   "create_weight_count": 1,
   "next_doc": 53876,
   "next_doc_count": 5,
   "advance": 0,
   "advance_count": 0,
   "compute_max_score": 0,
   "compute_max_score_count": 0,
   "shallow_advance": 0,
   "shallow_advance_count": 0,
   "set_min_competitive_score": 0,
   "set_min_competitive_score_count": 0
}</pre>
</div>
<p>Timings are listed in wall-clock nanoseconds and are not normalized at all. All
caveats about the overall <code class="literal">time_in_nanos</code> apply here.  The intention of the
breakdown is to give you a feel for A) what machinery in Lucene is actually
eating time, and B) the magnitude of differences in times between the various
components. Like the overall time, the breakdown is inclusive of all children
times.</p>
<p>The meaning of the stats are as follows:</p>
<h5>
<a id="_all_parameters"></a>All parameters:<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h5>
<div class="informaltable">
<table border="0" cellpadding="4px">
<colgroup>
<col>
<col>
</colgroup>
<tbody valign="top">
<tr>
<td valign="top">
<p>
<code class="literal">create_weight</code>
</p>
</td>
<td valign="top">
<p>
A Query in Lucene must be capable of reuse across multiple IndexSearchers (think of it as the engine that
executes a search against a specific Lucene Index).  This puts Lucene in a tricky spot, since many queries
need to accumulate temporary state/statistics associated with the index it is being used against, but the
Query contract mandates that it must be immutable.
<br>
<br>
To get around this, Lucene asks each query to generate a Weight object which acts as a temporary context
object to hold state associated with this particular (IndexSearcher, Query) tuple.  The <code class="literal">weight</code> metric
shows how long this process takes
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">build_scorer</code>
</p>
</td>
<td valign="top">
<p>
This parameter shows how long it takes to build a Scorer for the query.  A Scorer is the mechanism that
iterates over matching documents and generates a score per-document (e.g. how well does "foo" match the document?).
Note, this records the time required to generate the Scorer object, not actually score the documents.  Some
queries have faster or slower initialization of the Scorer, depending on optimizations, complexity, etc.
<br>
<br>
This may also show timing associated with caching, if enabled and/or applicable for the query
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">next_doc</code>
</p>
</td>
<td valign="top">
<p>
The Lucene method <code class="literal">next_doc</code> returns Doc ID of the next document matching the query.  This statistic shows
the time it takes to determine which document is the next match, a process that varies considerably depending
on the nature of the query.   Next_doc is a specialized form of advance() which is more convenient for many
queries in Lucene.  It is equivalent to advance(docId() + 1)
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">advance</code>
</p>
</td>
<td valign="top">
<p>
<code class="literal">advance</code> is the "lower level" version of next_doc: it serves the same purpose of finding the next matching
doc, but requires the calling query to perform extra tasks such as identifying and moving past skips, etc.
However,  not all queries can use next_doc, so <code class="literal">advance</code> is also timed for those queries.
<br>
<br>
Conjunctions (e.g. <code class="literal">must</code> clauses in a boolean) are typical consumers of <code class="literal">advance</code>
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">match</code>
</p>
</td>
<td valign="top">
<p>
Some queries, such as phrase queries, match documents using a "two-phase" process.  First, the document is
"approximately" matched, and if it matches approximately, it is checked a second time with a more rigorous
(and expensive) process.  The second phase verification is what the <code class="literal">match</code> statistic measures.
<br>
<br>
For example, a phrase query first checks a document approximately by ensuring all terms in the phrase are
present in the doc.  If all the terms are present, it then executes the second phase verification to ensure
the terms are in-order to form the phrase, which is relatively more expensive than just checking for presence
of the terms.
<br>
<br>
Because this two-phase process is only used by a handful of queries, the <code class="literal">match</code> statistic is often zero
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">score</code>
</p>
</td>
<td valign="top">
<p>
This records the time taken to score a particular document via its Scorer
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">*_count</code>
</p>
</td>
<td valign="top">
<p>
Records the number of invocations of the particular method.  For example, <code class="literal">"next_doc_count": 2,</code>
means the <code class="literal">nextDoc()</code> method was called on two different documents.  This can be used to help judge
how selective queries are, by comparing counts between different query components.
</p>
</td>
</tr>
</tbody>
</table>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="collectors-section"></a><code class="literal">collectors</code> Section<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The Collectors portion of the response shows high-level execution details.
Lucene works by defining a "Collector" which is responsible for coordinating the
traversal, scoring, and collection of matching documents.  Collectors are also
how a single query can record aggregation results, execute unscoped "global"
queries, execute post-query filters, etc.</p>
<p>Looking at the previous example:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">"collector": [
   {
      "name": "SimpleTopScoreDocCollector",
      "reason": "search_top_hits",
      "time_in_nanos": "32273"
   }
]</pre>
</div>
<p>We see a single collector named <code class="literal">SimpleTopScoreDocCollector</code> wrapped into
<code class="literal">CancellableCollector</code>. <code class="literal">SimpleTopScoreDocCollector</code> is the default "scoring and
sorting" <code class="literal">Collector</code> used by Elasticsearch. The <code class="literal">reason</code> field attempts to give a plain
English description of the class name.  The <code class="literal">time_in_nanos</code> is similar to the
time in the Query tree: a wall-clock time inclusive of all children. Similarly,
<code class="literal">children</code> lists all sub-collectors. The <code class="literal">CancellableCollector</code> that wraps
<code class="literal">SimpleTopScoreDocCollector</code> is used by Elasticsearch to detect if the current search was
cancelled and stop collecting documents as soon as it occurs.</p>
<p>It should be noted that Collector times are <span class="strong strong"><strong>independent</strong></span> from the Query
times.  They are calculated, combined, and normalized independently! Due to the
nature of Lucene’s execution, it is impossible to "merge" the times from the
Collectors into the Query section, so they are displayed in separate portions.</p>
<p>For reference, the various collector reasons are:</p>
<div class="informaltable">
<table border="0" cellpadding="4px">
<colgroup>
<col>
<col>
</colgroup>
<tbody valign="top">
<tr>
<td valign="top">
<p>
<code class="literal">search_sorted</code>
</p>
</td>
<td valign="top">
<p>
A collector that scores and sorts documents.  This is the most common collector and will be seen in most
simple searches
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">search_count</code>
</p>
</td>
<td valign="top">
<p>
A collector that only counts the number of documents that match the query, but does not fetch the source.
This is seen when <code class="literal">size: 0</code> is specified
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">search_terminate_after_count</code>
</p>
</td>
<td valign="top">
<p>
A collector that terminates search execution after <code class="literal">n</code> matching documents have been found.  This is seen
when the <code class="literal">terminate_after_count</code> query parameter has been specified
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">search_min_score</code>
</p>
</td>
<td valign="top">
<p>
A collector that only returns matching documents that have a score greater than <code class="literal">n</code>.  This is seen when
the top-level parameter <code class="literal">min_score</code> has been specified.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">search_multi</code>
</p>
</td>
<td valign="top">
<p>
A collector that wraps several other collectors.  This is seen when combinations of search, aggregations,
global aggs, and post_filters are combined in a single search.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">search_timeout</code>
</p>
</td>
<td valign="top">
<p>
A collector that halts execution after a specified period of time.  This is seen when a <code class="literal">timeout</code> top-level
parameter has been specified.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">aggregation</code>
</p>
</td>
<td valign="top">
<p>
A collector that Elasticsearch uses to run aggregations against the query scope.  A single <code class="literal">aggregation</code>
collector is used to collect documents for <span class="strong strong"><strong>all</strong></span> aggregations, so you will see a list of aggregations
in the name rather.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">global_aggregation</code>
</p>
</td>
<td valign="top">
<p>
A collector that executes an aggregation against the global query scope, rather than the specified query.
Because the global scope is necessarily different from the executed query, it must execute its own
match_all query (which you will see added to the Query section) to collect your entire dataset
</p>
</td>
</tr>
</tbody>
</table>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="rewrite-section"></a><code class="literal">rewrite</code> Section<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>All queries in Lucene undergo a "rewriting" process.  A query (and its
sub-queries) may be rewritten one or more times, and the process continues until
the query stops changing.  This process allows Lucene to perform optimizations,
such as removing redundant clauses, replacing one query for a more efficient
execution path, etc. For example a Boolean → Boolean → TermQuery can be
rewritten to a TermQuery, because all the Booleans are unnecessary in this case.</p>
<p>The rewriting process is complex and difficult to display, since queries can
change drastically. Rather than showing the intermediate results, the total
rewrite time is simply displayed as a value (in nanoseconds). This value is
cumulative and contains the total time for all queries being rewritten.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_a_more_complex_example"></a>A more complex example<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>To demonstrate a slightly more complex query and the associated results, we can
profile the following query:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET /twitter/_search
{
  "profile": true,
  "query": {
    "term": {
      "user": {
        "value": "test"
      }
    }
  },
  "aggs": {
    "my_scoped_agg": {
      "terms": {
        "field": "likes"
      }
    },
    "my_global_agg": {
      "global": {},
      "aggs": {
        "my_level_agg": {
          "terms": {
            "field": "likes"
          }
        }
      }
    }
  },
  "post_filter": {
    "match": {
      "message": "some"
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/2048.console"></div>
<p>This example has:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
A query
</li>
<li class="listitem">
A scoped aggregation
</li>
<li class="listitem">
A global aggregation
</li>
<li class="listitem">
A post_filter
</li>
</ul>
</div>
<p>The API returns the following result:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
   ...
   "profile": {
         "shards": [
            {
               "id": "[P6-vulHtQRWuD4YnubWb7A][test][0]",
               "searches": [
                  {
                     "query": [
                        {
                           "type": "TermQuery",
                           "description": "message:some",
                           "time_in_nanos": "409456",
                           "breakdown": {
                              "score": 0,
                              "build_scorer_count": 1,
                              "match_count": 0,
                              "create_weight": 31584,
                              "next_doc": 0,
                              "match": 0,
                              "create_weight_count": 1,
                              "next_doc_count": 2,
                              "score_count": 1,
                              "build_scorer": 377872,
                              "advance": 0,
                              "advance_count": 0,
                              "compute_max_score": 0,
                              "compute_max_score_count": 0,
                              "shallow_advance": 0,
                              "shallow_advance_count": 0,
                              "set_min_competitive_score": 0,
                              "set_min_competitive_score_count": 0
                           }
                        },
                        {
                           "type": "TermQuery",
                           "description": "user:test",
                           "time_in_nanos": "303702",
                           "breakdown": {
                              "score": 0,
                              "build_scorer_count": 1,
                              "match_count": 0,
                              "create_weight": 185215,
                              "next_doc": 5936,
                              "match": 0,
                              "create_weight_count": 1,
                              "next_doc_count": 2,
                              "score_count": 1,
                              "build_scorer": 112551,
                              "advance": 0,
                              "advance_count": 0,
                              "compute_max_score": 0,
                              "compute_max_score_count": 0,
                              "shallow_advance": 0,
                              "shallow_advance_count": 0,
                              "set_min_competitive_score": 0,
                              "set_min_competitive_score_count": 0
                           }
                        }
                     ],
                     "rewrite_time": 7208,
                     "collector": [
                        {
                          "name": "MultiCollector",
                          "reason": "search_multi",
                          "time_in_nanos": 1820,
                          "children": [
                            {
                              "name": "FilteredCollector",
                              "reason": "search_post_filter",
                              "time_in_nanos": 7735,
                              "children": [
                                {
                                  "name": "SimpleTopScoreDocCollector",
                                  "reason": "search_top_hits",
                                  "time_in_nanos": 1328
                                }
                              ]
                            },
                            {
                              "name": "MultiBucketCollector: [[my_scoped_agg, my_global_agg]]",
                              "reason": "aggregation",
                              "time_in_nanos": 8273
                            }
                          ]
                        }
                     ]
                  }
               ],
               "aggregations": [...] <a id="CO640-1"></a><i class="conum" data-value="1"></i>
            }
         ]
      }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO640-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>The <code class="literal">"aggregations"</code> portion has been omitted because it will be covered in
the next section.</p>
</td>
</tr>
</table>
</div>
<p>As you can see, the output is significantly more verbose than before.  All the
major portions of the query are represented:</p>
<div class="olist orderedlist">
<ol class="orderedlist">
<li class="listitem">
The first <code class="literal">TermQuery</code> (user:test) represents the main <code class="literal">term</code> query.
</li>
<li class="listitem">
The second <code class="literal">TermQuery</code> (message:some) represents the <code class="literal">post_filter</code> query.
</li>
</ol>
</div>
<p>The Collector tree is fairly straightforward, showing how a single
CancellableCollector wraps a MultiCollector which also wraps a FilteredCollector
to execute the post_filter (and in turn wraps the normal scoring
SimpleCollector), a BucketCollector to run all scoped aggregations.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_understanding_multitermquery_output"></a>Understanding MultiTermQuery output<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>A special note needs to be made about the <code class="literal">MultiTermQuery</code> class of queries.
This includes wildcards, regex, and fuzzy queries. These queries emit very
verbose responses, and are not overly structured.</p>
<p>Essentially, these queries rewrite themselves on a per-segment basis. If you
imagine the wildcard query <code class="literal">b*</code>, it technically can match any token that begins
with the letter "b".  It would be impossible to enumerate all possible
combinations, so Lucene rewrites the query in context of the segment being
evaluated, e.g., one segment may contain the tokens <code class="literal">[bar, baz]</code>, so the query
rewrites to a BooleanQuery combination of "bar" and "baz".  Another segment may
only have the token <code class="literal">[bakery]</code>, so the query rewrites to a single TermQuery for
"bakery".</p>
<p>Due to this dynamic, per-segment rewriting, the clean tree structure becomes
distorted and no longer follows a clean "lineage" showing how one query rewrites
into the next.  At present time, all we can do is apologize, and suggest you
collapse the details for that query’s children if it is too confusing. Luckily,
all the timing statistics are correct, just not the physical layout in the
response, so it is sufficient to just analyze the top-level MultiTermQuery and
ignore its children if you find the details too tricky to interpret.</p>
<p>Hopefully this will be fixed in future iterations, but it is a tricky problem to
solve and still in-progress. :)</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="profiling-aggregations"></a>Profiling Aggregations<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<div class="section">
<div class="titlepage"><div><div>
<h5 class="title">
<a id="agg-section"></a><code class="literal">aggregations</code> Section<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h5>
</div></div></div>
<p>The <code class="literal">aggregations</code> section contains detailed timing of the aggregation tree
executed by a particular shard. The overall structure of this aggregation tree
will resemble your original Elasticsearch request. Let’s execute the previous query again
and look at the aggregation profile this time:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET /twitter/_search
{
  "profile": true,
  "query": {
    "term": {
      "user": {
        "value": "test"
      }
    }
  },
  "aggs": {
    "my_scoped_agg": {
      "terms": {
        "field": "likes"
      }
    },
    "my_global_agg": {
      "global": {},
      "aggs": {
        "my_level_agg": {
          "terms": {
            "field": "likes"
          }
        }
      }
    }
  },
  "post_filter": {
    "match": {
      "message": "some"
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/2049.console"></div>
<p>This yields the following aggregation profile output:</p>
<div class="pre_wrapper lang-console-result">
<pre class="programlisting prettyprint lang-console-result">{
  "profile" : {
    "shards" : [
      {
        "aggregations" : [
          {
            "type" : "LongTermsAggregator",
            "description" : "my_scoped_agg",
            "time_in_nanos" : 195386,
            "breakdown" : {
              "reduce" : 0,
              "build_aggregation" : 81171,
              "build_aggregation_count" : 1,
              "initialize" : 22753,
              "initialize_count" : 1,
              "reduce_count" : 0,
              "collect" : 91456,
              "collect_count" : 4
            }
          },
          {
            "type" : "GlobalAggregator",
            "description" : "my_global_agg",
            "time_in_nanos" : 190430,
            "breakdown" : {
              "reduce" : 0,
              "build_aggregation" : 59990,
              "build_aggregation_count" : 1,
              "initialize" : 29619,
              "initialize_count" : 1,
              "reduce_count" : 0,
              "collect" : 100815,
              "collect_count" : 4
            },
            "children" : [
              {
                "type" : "LongTermsAggregator",
                "description" : "my_level_agg",
                "time_in_nanos" : 160329,
                "breakdown" : {
                  "reduce" : 0,
                  "build_aggregation" : 55712,
                  "build_aggregation_count" : 1,
                  "initialize" : 10559,
                  "initialize_count" : 1,
                  "reduce_count" : 0,
                  "collect" : 94052,
                  "collect_count" : 4
                }
              }
            ]
          }
        ]
      }
    ]
  }
}</pre>
</div>
<p>From the profile structure we can see that the <code class="literal">my_scoped_agg</code> is internally
being run as a <code class="literal">LongTermsAggregator</code> (because the field it is aggregating,
<code class="literal">likes</code>, is a numeric field). At the same level, we see a <code class="literal">GlobalAggregator</code>
which comes from <code class="literal">my_global_agg</code>. That aggregation then has a child
<code class="literal">LongTermsAggregator</code> which comes from the second term’s aggregation on <code class="literal">likes</code>.</p>
<p>The <code class="literal">time_in_nanos</code> field shows the time executed by each aggregation, and is
inclusive of all children.  While the overall time is useful, the <code class="literal">breakdown</code>
field will give detailed stats about how the time was spent.</p>
</div>

</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_timing_breakdown_2"></a>Timing Breakdown<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>The <code class="literal">breakdown</code> component lists detailed timing statistics about low-level
Lucene execution:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">"breakdown": {
  "reduce": 0,
  "reduce_count": 0,
  "build_aggregation": 49765,
  "build_aggregation_count": 300,
  "initialize": 52785,
  "initialize_count": 300,
  "reduce_count": 0,
  "collect": 3155490036,
  "collect_count": 1800
}</pre>
</div>
<p>Timings are listed in wall-clock nanoseconds and are not normalized at all. All
caveats about the overall <code class="literal">time</code> apply here.  The intention of the breakdown is
to give you a feel for A) what machinery in Elasticsearch is actually eating time, and B)
the magnitude of differences in times between the various components. Like the
overall time, the breakdown is inclusive of all children times.</p>
<p>The meaning of the stats are as follows:</p>
<h5>
<a id="_all_parameters_2"></a>All parameters:<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h5>
<div class="informaltable">
<table border="0" cellpadding="4px">
<colgroup>
<col>
<col>
</colgroup>
<tbody valign="top">
<tr>
<td valign="top">
<p>
<code class="literal">initialise</code>
</p>
</td>
<td valign="top">
<p>
This times how long it takes to create and initialise the aggregation before starting to collect documents.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">collect</code>
</p>
</td>
<td valign="top">
<p>
This represents the cumulative time spent in the collect phase of the aggregation. This is where matching documents are passed to the aggregation and the state of the aggregator is updated based on the information contained in the documents.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">build_aggregation</code>
</p>
</td>
<td valign="top">
<p>
This represents the time spent creating the shard level results of the aggregation ready to pass back to the reducing node after the collection of documents is finished.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">reduce</code>
</p>
</td>
<td valign="top">
<p>
This is not currently used and will always report <code class="literal">0</code>. Currently aggregation profiling only times the shard level parts of the aggregation execution. Timing of the reduce phase will be added later.
</p>
</td>
</tr>
<tr>
<td valign="top">
<p>
<code class="literal">*_count</code>
</p>
</td>
<td valign="top">
<p>
Records the number of invocations of the particular method.  For example, <code class="literal">"collect_count": 2,</code>
means the <code class="literal">collect()</code> method was called on two different documents.
</p>
</td>
</tr>
</tbody>
</table>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="profiling-considerations"></a>Profiling Considerations<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<p>Like any profiler, the Profile API introduces a non-negligible overhead to
search execution. The act of instrumenting low-level method calls such as
<code class="literal">collect</code>, <code class="literal">advance</code>, and <code class="literal">next_doc</code> can be fairly expensive, since these
methods are called in tight loops.  Therefore, profiling should not be enabled
in production settings by default, and should not be compared against
non-profiled query times. Profiling is just a diagnostic tool.</p>
<p>There are also cases where special Lucene optimizations are disabled, since they
are not amenable to profiling. This could cause some queries to report larger
relative times than their non-profiled counterparts, but in general should not
have a drastic effect compared to other components in the profiled query.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="profile-limitations"></a>Limitations<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/search/profile.asciidoc">edit</a>
</h4>
</div></div></div>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Profiling currently does not measure the search fetch phase nor the network
overhead.
</li>
<li class="listitem">
Profiling also does not account for time spent in the queue, merging shard
responses on the coordinating node, or additional work such as building global
ordinals (an internal data structure used to speed up search).
</li>
<li class="listitem">
Profiling statistics are currently not available for suggestions,
highlighting, <code class="literal">dfs_query_then_fetch</code>.
</li>
<li class="listitem">
Profiling of the reduce phase of aggregation is currently not available.
</li>
<li class="listitem">
The Profiler is still highly experimental. The Profiler is instrumenting parts
of Lucene that were never designed to be exposed in this manner, and so all
results should be viewed as a best effort to provide detailed diagnostics. We
hope to improve this over time. If you find obviously wrong numbers, strange
query structures, or other bugs, please report them!
</li>
</ul>
</div>
</div>

</div>

</div>
<div class="navfooter">
<span class="prev">
<a href="search-explain.html">« Explain API</a>
</span>
<span class="next">
<a href="search-field-caps.html">Field Capabilities API »</a>
</span>
</div>
</div>

                  <!-- end body -->
                </div>
                <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                  <div id="rtpcontainer" style="display: block;">
                    <div class="mktg-promo">
                      <h3>Most Popular</h3>
                      <ul class="icons">
                        <li class="icon-elasticsearch-white"><a href="https://www.elastic.co/webinars/getting-started-elasticsearch?baymax=default&amp;elektra=docs&amp;storm=top-video">Get Started with Elasticsearch: Video</a></li>
                        <li class="icon-kibana-white"><a href="https://www.elastic.co/webinars/getting-started-kibana?baymax=default&amp;elektra=docs&amp;storm=top-video">Intro to Kibana: Video</a></li>
                        <li class="icon-logstash-white"><a href="https://www.elastic.co/webinars/introduction-elk-stack?baymax=default&amp;elektra=docs&amp;storm=top-video">ELK for Logs &amp; Metrics: Video</a></li>
                      </ul>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </section>

        </div>


<div id="elastic-footer"></div>
<script src="https://www.elastic.co/elastic-footer.js"></script>
<!-- Footer Section end-->

      </section>
    </div>

<script src="/guide/static/jquery.js"></script>
<script type="text/javascript" src="/guide/static/docs.js"></script>
<script type="text/javascript">
  window.initial_state = {}</script>
  </body>
</html>
